Summary

Walks back the release-plz setup (#691) in favor of a simple tag-driven workflow. release-plz turned out to be the wrong tool for this repo because:

1. Org-level policy blocks it. Dstack-TEE disallows GitHub Actions from creating pull requests, which is the central mechanism release-plz uses. The Release PR creation step returns HTTP 403 and there's no clean workaround that doesn't require a PAT or custom GitHub App.
2. Overkill for this cadence. The SDK has 2 coupled crates that share a version and ship infrequently. PR-driven automation with auto-bump and changelog scanning is solving a problem we don't have.

This switches to an idempotent, validated tag-driven publish that fixes every concrete failure mode from the old workflow.

What changes

• New .github/workflows/rust-sdk-release.yml (replaces the previous content):

  • Triggers on dstack-sdk-v* tags only (single tag for both crates — they share a version).
  • Validates that the tag version matches all three sources before publishing:
    • sdk/rust/types/Cargo.toml [package.version]
    • sdk/rust/Cargo.toml [package.version]
    • root Cargo.toml [workspace.dependencies.dstack-sdk-types.version]
    • Fails fast with a clear message if any drift — directly fixes the rust-sdk-v0.5.9 vs 0.1.2 failure mode that broke the previous publishes.
  • Publishes via .github/scripts/cargo-publish-idempotent.sh: cargo publish is wrapped so "already exists on crates.io" is treated as success. A partial-failure mid-release can be retried by pushing the same tag, without getting stuck on the first crate.
  • Auto-creates a matching GitHub Release.
  • Same environment: sdk-release + OIDC trusted publishing as before, so existing crates.io trusted publisher config keeps working.

• New .github/scripts/cargo-publish-idempotent.sh — the wrapper described above.

• Removed release-plz.toml.

How to release (human-facing)

# Bump versions (cargo-edit's set-version; cargo install cargo-edit if missing)
cargo set-version -p dstack-sdk-types -p dstack-sdk 0.1.3

# Also bump the workspace dependency pin in root Cargo.toml
#   dstack-sdk-types = { path = "sdk/rust/types", version = "0.1.3", ... }

git commit -am "release: dstack-sdk 0.1.3"
git tag dstack-sdk-v0.1.3
git push origin master dstack-sdk-v0.1.3

If you forget to bump one of the three version sources, the workflow fails with a checklist showing which one is wrong, before touching crates.io.

Existing drift uncovered

The current Cargo.toml workspace dep pin is 0.1.1 while both crates are at 0.1.2. The validator catches this — the next release tag must include a fixed workspace dep pin.

Test plan

• CI green on the PR
• After merge: bump versions to 0.1.3 (including the workspace dep pin fix), tag dstack-sdk-v0.1.3, push, verify both crates publish to crates.io
• Verify idempotency by pushing the same tag again (delete + re-tag) — workflow should succeed without errors